This looks good! I see I'm too late to give an official approval, but I still wanted to leave a few thoughts:

Will we want the RelationshipAccessor to include the ComponentId of the reverse direction? Like, ChildOf would tell you Children and vice versa?

Given how few components are relationships, would we want to do something like relationship_accessor: Option<Box<RelationshipAccessor>>, to make the ComponentDescriptor smaller in the common case? I guess right now it's only two usizes, so that wouldn't actually save much.

Will we want the RelationshipAccessor to include the ComponentId of the reverse direction? Like, ChildOf would tell you Children and vice versa?

I've thought about adding that, but that'll require initializing this field after creating the ComponentDescriptor for a Component (or passing Components to ComponentDescriptor::new, which is actually not too bad as it's available in those contexts either way). I'm not entirely sure what use case that would be useful for though. The only one I can come up with is removing the relationship when traversing them from the RelationshipTarget side, which might be useful. But I do agree that this is something that should be stored to make relationships support more first-class in the untyped context.

Given how few components are relationships, would we want to do something like relationship_accessor: Option<Box<RelationshipAccessor>>, to make the ComponentDescriptor smaller in the common case? I guess right now it's only two usizes, so that wouldn't actually save much.

Yeah, that makes sense. Ideally we'd have components-as-entities so that ComponentDescriptor can be split up, but even then making a safe interface around that would be quite a challenge.

@urben1680 also mentioned that a flag indicating whether there is any other data besides Entity/Collection present on these components will be useful, so maybe these can be put in a follow up PR (along with changes required for whatever solution we land on for many-to-many relationships).

I've thought about adding that, but that'll require initializing this field after creating the ComponentDescriptor for a Component

Oh, right, there are links in both directions, so you can't just register one component first and then pass it to the other. Yeah, that's harder than I thought!

I'm not entirely sure what use case that would be useful for though.

The reason it's on my mind is that I'm trying to figure out how to safely allow mutable query access through Children for #17647, and my current thought is that we'll need to read the ChildOf component and ensure it matches the expected parent. If that does turn out to be the way to do that, then we'll eventually want an untyped way to do that.

The reason it's on my mind is that I'm trying to figure out how to safely allow mutable query access through Children

Because we can't trust that RelationshipTarget's data is correct since there are escape hatches for mutating it? I guess that wouldn't be a problem if RelationshipTarget's collection mutation was unsafe and also guaranteed to contain unique entities? Makes sense, although that won't work for more than 1 level of relationship traversal (i.e. Query<(&mut Comp, Related<Children, (&mut Comp, Related<OtherRelation, &mut Comp>)>)>), right? But I do see how it can be useful for that, yes.